%%This is a very basic article template.
%%There is just one section and two subsections.
\documentclass[11pt]{article}
\linespread{1}
\usepackage[brazil]{babel}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage[margin=2cm]{geometry}
\usepackage{array}
 
\begin{document}

\begin{figure}[t]
\center
\includegraphics[width=13cm]{images/cabecalho.png}
\end{figure}

\begin{center}
\textbf{GERÊNCIA DE CAPACIDADE BASEADA EM MÉTRICAS DE NEGÓCIO PARA
APLICAÇÕES DE SOFTWARE COMO UM SERVIÇO} 
\linebreak\end{center}

\small

\begin{center}
\textbf{Lília Rodrigues Sampaio}\footnote{Aluna do Curso de
Ciência da Computação, Centro de Engenharia Elétrica e Informática, Departamento de
Sistemas e Computação, UFCG, Campina Grande, PB, E-mail:liliars@lsd.ufcg.edu.br}
\textbf{, Raquel Vigolvino Lopes}\footnote{Ciência da Computação, Professora.
Doutora, Centro de Engenharia Elétrica e Informática, Departamento de Sistemas 
e Computação, UFCG, Campina Grande, PB, E-mail:raquel@dsc.ufcg.edu.br} 
\linebreak\linebreak

\textbf{RESUMO}
\end{center}

A Computação na Nuvem se propõe a fornecer serviços em vários níveis,
tornando possível desde o armazenamento de dados e provimento de recursos
computacionais sob-demanda até o acesso a um software através da
Internet. Em se tratando do serviço de ``Software como um
serviço'' (do inglês, SaaS - Software as a Service), é importante gerenciar a
capacidade das aplicações oferecidas. Tradicionalmente, utilizam-se duas
técnicas específicas para gerenciamento a longo e curto prazo dos recursos, o
planejamento de capacidade e o escalonamento de aplicações, respectivamente.
Este trabalho foi, então, desenvolvido nesse contexto, tendo sido organizado
em duas etapas. Primeiramente, foram
realizadas atividades de verificação e testes em um simulador desenvolvido com a finalidade de
apoiar experimentos na área de planejamento de capacidade. Em uma segunda
etapa, iniciamos a avaliação de um novo serviço identificado no mercado
dos provedores na nuvem, o escalonamento automático de aplicações. Essa técnica
consiste em escalonar dinamicamente a quantidade de recursos, baseado em
condições definidas pelo usuário e especificadas 
considerando métricas coletadas por um monitor ligado à aplicação. 
Dado que diversos algoritmos de provisionamento dinâmico foram propostos para 
utilização dentro das técnicas de planejamento e escalonamento, decidimos
avaliar a possibilidade de implementação de alguns dos mais importantes neste
novo serviço, bem como suas vantagens e desvantagens considerando métricas de negócio. \newline

\textbf{Palavras-chave:} computação na nuvem, escalonamento automático,
provisionamento e métricas de negócio \newline

\begin{center}
\textbf{CAPACITY PLANNING BASED ON BUSINESS METRICS FOR
APLICATIONS OF SOFTWARE AS A SERVICE}\linebreak\linebreak
\textbf{ABSTRACT}
\end{center}

Cloud Computing has the purpose of providing services in different
levels, making possible since the data storage and computing resources on
demand, until the acess to a software through the Internet. Regarding Software
as a Service (SaaS), it is important to manage the capacity of the
applications provided. Traditionally, in order to manage such the resources
available it should be used specific techniques in the short and long
term, called applications scheduling and capacity planning, respectively. 
This research was developed in this context, and it was organized in two steps. 
Firstly, verification activities and tests were performed in a simulator 
developed with the finality of supporting experiments in the capacity  planning
area. In the second step, we started an evaluation of a new service  identified
in the market of cloud providers as applications auto scaling. This  technique
consists in scheduling dynamically the amount of resources, based on  conditions
defined by the user itself, and that are specified considering metrics 
collected by a monitor connected to  the application. Since there are a 
diversity of provisioning algorithms used in combination with the capacity 
planning and applications scheduling  techniques, we decided to evaluate  the
viability of implementation of the most  important ones using this new auto 
scaling service, as well as the advantages and disadvantages of using this 
service considering business metrics. \newline

\textbf{Keywords:} cloud computing, auto scaling, provisioning and business
metrics \newline \newpage

\begin{center}
\textbf{INTRODUÇÃO}
\end{center}

A Computação na Nuvem é uma área que vem crescendo bastante nos
últimos anos. Esse serviço se propõe a, por exemplo, fornecer recursos
virtuais de forma que seja possível  armazenar dados,  prover recursos
computacionais sob-demanda ou mesmo o acesso a um software  através da Internet.
Podemos destacar algumas vantagens do uso de computação na  nuvem como um bom
recurso para o desenvolvimento de aplicações (MENASCÉ; NGO, 2009):\newline

a. Pay-per-use: a cobrança pelo serviço é baseada apenas
nos recursos que foram utilizados pelo usuário, seja durante certo tempo ou por
quantidade.

b. Facilidade no acesso à aplicação: os softwares e dados podem ser acessados de
qualquer lugar, sendo necessária apenas a conexão à Internet.

c. Tempo para o negócio: dado que não é mais de responsabilidade do cliente
lidar com a infraestrutura da aplicação, bem como com sua manutenção, sobra mais
tempo para dedicar-se ao negócio propriamente dito, sendo agora esse um serviço
executado pelo provedor na nuvem.\newline

Além disso, os serviços oferecidos através da Computação na Nuvem podem ser
divididos em níveis, como segue na tabela:\newline

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}m{4cm}|>{\small}m{8cm}|>{\small}m{4cm}|}  
\hline
\centering{NÍVEL} & \centering{FUNÇÃO} & EXEMPLOS\\  
\hline
IAAS (do inglês, Infrastructure as a Service) & São oferecidos serviços como
processamento e armazenamento. Esses provedores oferecem a possibilidade de
reserva de recursos em longo prazo (mercado de reservas), ou ainda, a aquisição
de recursos no curto prazo (mercado sob-demanda) & Amazon EC2, Rackspace\\
\hline 
PAAS (do inglês, Plataform as a Service) & Engloba ferramentas para
auxiliar desde o desenvolvimento de aplicações até a manutenção do ciclo de vida
delas. & Google App Engine\\
\hline 
SAAS (do inglês, Software as a Service) & Oferta aplicações prontas para o
usuário final & Customer Relationship Management (CRM), editores de texto,
entre outros\\
\hline 
\end{tabular}
\caption{\footnotesize Divisão dos serviços oferecidos através da computação na
nuvem em IAAS, PAAS e SAAS.}
\end{center}
\end{table}

O objeto principal de estudo nesse projeto é a camada de aplicação SaaS, cujo
nicho de atuação tem como exemplos: Enterprise Applications (finanças, CRM),
Enterprise Infrastructure Apps (banco de dados, servidores de email),
Information Worker Software (processador de texto, planilhas, sistemas de        
Informação Pessoal), Content Access (reprodutores de mídia, navegadores, jogos),
Product Engineering (editores de linguagem de máquina e compiladores, Integrated
Development Environments (IDE) e Application Programmer Interfaces (API)),    
dentre muitos outros.

Para realizar o gerenciamento da capacidade das aplicações SaaS dentro dos
provedores, existem as técnicas descritas como gerência de capacidade de longo e
curto prazo, também chamadas planejamento de capacidade e escalonamento,
respectivamente. A gerência de capacidade de certa infraestrutura pode ser
realizada sob duas óticas principais. Uma considerando métricas técnicas como,
por exemplo, tempo de resposta, e outra considerando métricas de negócio,
basicamente voltada para lucro versus gastos no negócio, sendo essa o foco desta
pesquisa.

Esta pesquisa de iniciação científica foi, então, dividida em duas etapas. A
primeira, contemplou a realização de testes
e atividades de verificação sobre um simulador, construído com o intuito de
servir como base para o estudo destas técnicas de planejamento de capacidade e
escalonamento de aplicações. 

É de conhecimento geral a importância de exaustivos
conjuntos de testes a cerca do funcionamento de um sistema em desenvolvimento.
Isso gera maior confiabilidade sobre a aplicação no que diz respeito à
experimentos realizados a partir de sua execução, além de facilitar o
desenvolvimento do próprio sistema, principalmente sob a ótica da agilidade em
encontrar e consertar possíveis erros. Este foi, portanto, o objetivo destas
atividades, gerar maior confiabilidade nos resultados dos experimentos
realizados a partir do simulador citado, encontrar possíveis erros
presentes em sua implementação para que os ajustes necessários pudessem ser
feitos, bem como a escrita de scripts que auxiliassem a automação da execução do
simulador e a obtenção de dados a cerca de aspectos como níveis de confiança da
simulação, testes de hipótese, tamanho da amostra, entre outros. 

Em uma segunda etapa, decidimos avaliar um novo serviço denominado escalonamento
automático de aplicações, o qual vem se firmando e sendo cada vez mais oferecido
pelos provedores IAAS presentes no mercado, com destaque para a Amazon EC2 e o   
Microsoft Azure. Ele permite escalar a capacidade de seu provedor para mais ou 
para menos, automaticamente, de acordo com regras definidas pelo usuário. Nesse
caso o número de instâncias utilizadas aumenta facilmente durante picos de
demanda para manter o desempenho e diminui automaticamente durante quedas para 
minimizar custos (Disponível em: <http://aws.amazon.com/pt/autoscaling/>).

Algumas grandes marcas já utilizam esse serviço para atender às necessidades
de suas aplicações, como por exemplo o Netflix. Esta empresa é o principal
serviço de assinatura de filmes e séries de TV pela Internet do mundo, com mais
de 25 milhões de assinantes. Recentemente, ela divulgou um artigo relatando a
experiência com o serviço, onde se mostrava bastante satisfeita com os
resultados em performance e custo-benefício, enfatizando a boa qualidade do
serviço em questão de disponibilidade e otimização nos custos.

De encontro à isso, temos que o serviço de escalonamento de aplicações e
gerência de capacidade já vem sendo estudado na área há um bom tempo, e portanto, diversos
algoritmos de provisionamento dinâmico foram propostos para a solução desse  
problema. Vieram então os questionamentos sobre a possibilidade da implementação
desses algoritmos por esse serviço de escalonamento automático de aplicações já 
oferecido dentro de alguns provedores, suas vantagens e desvantagens. 

Assim, dentro da pesquisa, tivemos como objetivo inicial a realização
de atividades de verificação e testes sobre um simulador construído para
a avaliação da técnica de gerência de capacidade abordada com base em métricas
de negócio, e após isso, considerando o surgimento
desse novo serviço de escalonamento automático de aplicações, investigamos uma
possível implementação de alguns dos principais algoritmos de provisionamento
dinâmico conhecidos, Ranjan e Urgaonkar, utilizando esse serviço disponível hoje no mercado.

Essa implementação foi baseada no serviço de escalonamento
automático fornecido pelo provedor Amazon EC2, e portanto, é importante
para o entendimento dos resultados, destacar conceitos válidos dentro desse
provedor e que serão utilizados posteriormente no que diz respeito aos
algoritmos e sua possivel implementação pelo escalonador.
Seu funcionamento é baseado no uso de Alarmes e Políticas para a configuração de
condições e ações que devem ser, respectivamente, checadas e realizadas pelo
escalonador para atender às necessidades definidas pelo  usuário.

Um Alarme funciona como um objeto que observa uma métrica, por exemplo. Ele pode
mudar de estado dependendo do valor dessa métrica observada, e quando isso
acontece, uma ou mais ações são executadas. Alarmes trabalham em conjunto com
Políticas, pois, quando uma condição é avaliada como verdadeira, um sinal é
enviado para a Política ligada ao Alarme 'acionado', que por sua vez será
responsável por executar ações específicas. É importante observar que, as
condições definidas dentro de um Alarme devem ser baseadas apenas em dados que o
monitor de aplicações (nesse caso, o Amazon CloudWAtch) seja capaz de
coletar.        

Políticas são um conjunto de ações que devem ser executadas quando determinadas
condições, verificadas por Alarmes ligados à elas, sejam avaliadas como
verdadeiras. Assim, dado que um Alarme seja 'acionado', as ações especificadas
para a Política relacionada serão executadas. 

Por exemplo, supondo que temos uma aplicação rodando na Amazon EC2 e desejamos
usar o escalonador automático de aplicações para definir comportamentos do serviço diante de determinadas
situações. Vamos então criar um Alarme ('AlarmeUp'), que será
responsável por checar se o uso de CPU das instâncias que estão rodando a
aplicação é maior que 80 por cento, e apontaremos esse alarme para determinada
Política ('Política Up') que será executada quando a condição estabelecida se
apresentar. Nesse caso, podemos estabelecer que a PolíticaUp deverá criar 2
novas instâncias, por exemplo. Outro Alarme ('AlarmeDown') verificará se o uso
de CPU das instâncias é menor que 20 por cento e apontará para uma Política
('PoliticaDown') que removerá 2 máquinas, por exemplo.
 
O monitor de aplicações (nesse caso, o Amazon CloudWatch) passa então a
monitorar a aplicação, até que em dado momento, um pico de acesso acontece, e a
condição do AlarmeUp é verificada. Nesse caso, ele irá enviar uma mensagem ao
escalonador e este redirecionará o comando para a política específica desse
alarme, nesse caso a PoliticaUp. Com duas novas máquinas a aplicação funciona
perfeitamente até o fim do pico, quando então o AlarmeDown é ativado e duas
máquinas deverão ser removidas.      

Concluímos, então, que não houve necessidade do usuário verificar por ele mesmo
que necessitava comprar mais máquinas ou removê-las, pois, ao definir Alarmes e
Políticas especificando tais ações, o escalonador junto com o monitor se
responsabilizou por checar e reagir à esses acontecimentos, tal qual a proposta
do serviço de escalonamento automático. 

Assim, daqui por diante, quando falarmos em Alarmes e Políticas, estaremos
nos referindo aos objetos descritos aqui. 
\newpage

\begin{center}
\textbf{MATERIAL E MÉTODOS}
\end{center}    

Para a realização do conjunto de testes sobre o simulador abordado, foram
utilizadas as bibliotecas de teste JUnit e EasyMock. Os resultados referentes à
cobertura desses testes foram obtidos de forma automatizada, a partir da
utilização de uma ferramenta denominada Clover desenvolvido pela Atlassian.
Esse aplicativo permite a análise do código, indicando as partes ainda não
testadas, e a cobertura total do sistema em porcentagem.   

Para a análise quanto à possibilidade de implementação dos algoritmos de
provisionamento Ranjan e Urgaonkar pelo serviço de escalonamento automático de
aplicações, foi realizado primeiramente um estudo comparativo entre os mais
significativos para o meio, Amazon EC2, Windows Azure e Rackspace.  Esse estudo
incluiu a verificação dos serviços oferecidos internamente dentro do escalonador automático, em conjunto
com o monitor da aplicação. Além disso, uma tabela englobando as métricas
mais importantes coletadas por cada monitor também foi construída.
Posteriormente, ambas serão utilizadas para verificação a cerca da coleta de
dados necessária para a implementação de cada algoritmo. Seguem as tabelas
construídas com as informações adquiridas a partir da API de cada serviço: \newline

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}b{9cm}|>{\small}c|>{\small}c|>{\small}c|}  
\hline
\centering{MÉTRICA} & AMAZON & AZURE & RACKSPACE\\
\hline 
1. Escalonamento ditado por regras criadas pelo usuário & x & x & -\\ 
\hline 
2. Escalonamento automático para menos & x & x & -\\
\hline 
3. Escalonamento automático para mais & x & x & -\\
\hline 
4. Uso de sistemas de monitoramento da aplicação em conjunto com o serviço de
escalonamento & x & x & -\\ 
\hline
5. Envio de mensagens ao usuário quando certa condição descrita em uma regra é
verificada & x & x & -\\ 
\hline
6. Sistema de verificação da ‘saúde’ das máquinas em uso durante o escalonamento
da aplicação & x & x & -\\ 
\hline
7. Armazenamento de dados a cerca do escalonamento da aplicação & - & x & -\\ 
\hline
8. Escalonamento baseado em verificações de gastos & x & x & -\\ 
\hline
9. Escalonamento baseado no tamanho das máquinas & - & - & -\\ 
\hline
10. Substituição de máquinas com funcionamento inadequado & x & x & -\\ 
\hline 
11. Definição de períodos de tempo durante os quais a aplicação deve ser checada
& x & x & -\\ 
\hline 
12. Rebalanceamento das máquinas entre zonas diferentes & x & x & -\\ 
\hline 
13. Checagem de regras por um certo período de tempo & x & x & -\\ 
\hline
14. Ligação imediata da máquina quando detectada sua necessidade & - & - & -\\ 
\hline 
15. Dupla verificação das condições definidas nas regras de escalonamento & x &
- & -\\ 
\hline  
16. Definição do usuário a cerca da configuração inicial das máquinas que serão
escalonadas & x & x & -\\ 
\hline 
17. Definição de um limite de máquinas que deseja escalonar & x &
x & -\\
\hline 
18. Armazenamento de regras de escalonamento já definidas na manutenção de uma
aplicação & - & x & -\\
\hline 
19. Permite a criação de regras de escalonamento baseadas na demanda da
aplicação em tempo real & x & x & -\\ 
\hline 
20. Criação de regras baseadas em contadores de performance personalizados & -
& x & -\\
\hline 
\end{tabular}
\caption{\footnotesize Tabela comparativa entre 3 atuais principais provedores
na nuvem quanto ao oferecimento de subserviços do escalonador automático de
aplicações. O 'x' representa serviço oferecido, e '-' os que não são
oferecidos.}
\end{center}
\end{table}

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}b{9cm}|>{\small}c|>{\small}c|>{\small}c|}  
\hline
\centering{MÉTRICA} & AMAZON & AZURE & RACKSPACE\\
\hline 
1. Taxa de utilização média da CPU & x & x & -\\
\hline 
2. Taxa de incremento ou decremento da demanda & - & x & -\\
\hline 
3. Tamanho da fila de requisições a serem processadas & x & x & -\\
\hline 
4. Performance da aplicação & x & x & -\\
\hline
5. Histórico da demanda & x & x & -\\
\hline
6. Atividade de rede & x & x & -\\
\hline
7. Utilização de disco & x & x & -\\
\hline
8. Conectividade com o banco de dados & x & x & -\\
\hline
9. Número de requisições completas & x & x & -\\
\hline
10. Número de requisições que chegaram & x & x & -\\
\hline 
\end{tabular}
\caption{\footnotesize Tabela comparativa entre os 3 atuais principais
provedores na nuvem, quanto às métricas de possível coleta pelo seus respectivos
monitoradores. O 'x' representa métrica coletada, e '-' as que não são
coletadas.}
\end{center}
\end{table}

Note que, em ambas as tabelas, os campos referentes aos serviços oferecidos pelo
provedor Rackspace, bem como os tipos de métricas coletadas, foram todos
marcados como indisponível, pois tal provedor não oferece diretamente os serviços de
escalonamento automático de aplicações. Ele apenas é suportado por alguns
gerenciadores de aplicações que funcionam como escalonadores, por exemplo, 
Scarl e RightScale. Ainda assim, decidimos adicioná-lo à pesquisa por se tratar
de um dos provedores na nuvem mais utilizado no mercado.

Para a verificação quanto à implementação de cada algoritmo de
provisionamento dinâmico, primeiramente foi realizado um estudo de artigos
e jornals de referência sobre eles, para entendimento de seu funcionamento bem
como o estado da arte da área. Desse estudo, identificamos quais eram os dados
necessários para a implementação de cada um e, tomando como base as informações
visualizadas nas tabelas acima, verificamos quais eram os de possível coleta
pelo monitor de aplicações. A partir disso, pudemos identificar, de maneira
parcial, a possibilidade de implementação através da descrição de alarmes e
políticas dentro do escalonador configurados por um usuário do serviço.

Em seguida, foi realizada a implementação propriamente dita desses algoritmos,
quando verificada sua possibilidade. Como dito anteriormente, o provedor escolhido para
a pesquisa foi o Amazon EC2, e portanto, tomamos como base a API de sua
ferramenta de escalonamento, o Auto Scaling. É importante ressaltar que tal
provedor possui licença paga, portanto, não pudemos rodar uma aplicação real
dentro do serviço, de tal forma que a implementação realizada foi baseada apenas
em sua API (Disponível em: http://aws.amazon.com/pt/documentation/autoscaling/)
e na do monitor (Disponível em: http://
aws.amazon.com/pt/documentation/cloudwatch/), além das necessidades dos algoritmos.
Houve portanto, um estudo detalhado quanto à documentação em Java dos serviços,
contemplando seus objetos e ações, viabilizando a implementação dos
algoritmos.

Mesmo diante dessa impossibilidade, pudemos realizar uma análise de custo,
considerando quanto seria necessário gastar para manter uma aplicação na nuvem
utilizando o escalonamento proposto por cada técnica estudada nos algoritmos, e
utilizando o serviço de Auto Scaling oferecido pelo provedor Amazon EC2.
Idealizamos alguns cenários simples definidos dentro desse contexto e então,
detectamos a viabilidade ou não de implementação de Ranjan e Urgaonkar
considerando não apenas a disponibilidade dos dados necessários, mas
também métricas de negócio.\newline

\textbf{Cenário definido para a análise de custo} \newline

A primeira característica importante a ser levada em consideração é o fato do
serviço de escalonamento automático propriamente dito não ser cobrado. O valor
pago é referente à utilização do serviço de monitoramento, o Amazon CloudWatch,
além do preço pago por instância utilizada. Aqui, consideraremos apenas o valor
referente ao monitoramento, já que o foco principal é o serviço de escalonamento
em si com base nos algoritmos de provisionamento dinâmico estudados.

A cobrança do Amazon CloudWatch é feita de acordo com o número de métricas do
Amazon CloudWatch monitoradas, a um valor de US\$ 0,50 por mês para cada
métrica, mais o número de alarmes utilizados, a um valor de US\$ 0,10 por mês
para cada alarme, considerando estes valores para cada instância. (Disponível
em: http://aws.amazon.com/pt/cloudwatch/)

Aqui, vamos considerar como exemplo, um desenvolvedor que deseja um
monitoramento detalhado de 20 instâncias do Amazon EC2 24 horas por dia, todos
os dias, por um mês de 30 dias. Isso tornará possível fazer a mesma análise para
um ano, posteriormente. \newline

\begin{center}
\textbf{RESULTADOS E DISCUSSÃO}
\end{center} 

\hspace{0,43cm} \textbf{Confiança no funcionamento do simulador a
partir da realização de casos de teste} \newline

Tomando como base os conhecimentos a respeito da importância em se realizar
testes sobre um sistema em desenvolvimento, o simulador foi testado em seus
componentes e heurísticas, permitindo assim que houvesse maior confiança
durante a realização de experimentos em sua execução. Também facilitou a
descoberta de erros de implementação, e visto que, ao decorrer dos testes casos
extremos foram testados, houve a detecção de gargalos com relação à sua
performance, com ênfase em seu tempo de execução.

Como dito anteriormente, usamos a ferramenta Clover para verificar a cobertura
de testes, e a partir dela foi possível a obtenção de relatórios de performance, como seguem.

\begin{figure}[h]
\center
\includegraphics[scale=0.8]{images/coverage1.png}
\caption{\footnotesize Cobertura do simulador abordado, subdividido em pacotes.}
\end{figure}

\hspace{0,43cm}\textbf{Análise dos algoritmos de provisionamento
dinâmico em conjunto com o Auto Scaling} \newline

Como já dito anteriormente, os algoritmos escolhidos para esta pesquisa foram
Ranjan e Urgaonkar. Aqui vamos descrever o funcionamento de cada um deles, o
resultado de sua possibilidade de implementação, e uma análise de custo baseada
em sua aplicação dentro do serviço de Auto Scaling da Amazon, provedor escolhido
como base para este estudo. O cenário utilizado nessas medições foi descrito na
seção Material e Métodos, e será o mesmo para ambos os algoritmos. \newline

\newpage
\textbf{1. Algoritmo Ranjan}\newline

\hspace{0,43cm}\textbf{1.1 Funcionamento}\newline

Este algoritmo é utilizado para modelos de aplicação com apenas uma camada, e
tem como saída um valor referente ao número ideal de máquinas para rodar dada
aplicação, mantendo uma utilização alvo (relacionada à média da utilização
das CPUs usadas) pré-definida. O cálculo desse valor é obtido através da
utilização de modelos matemáticos que incluem variáveis relacionadas ao número
de requisições que chegaram, destas, as que foram atendidas, além da média de
utilização das CPUs.

Após a obtenção do número ideal de máquinas, é feita uma comparação entre ele e
o número atual de máquinas utilizadas, e a partir disso, caso o valor
encontrado seja maior que o número atual, será realizada a inicialização de mais
máquinas, e se for menor, ocorrerá uma remoção do excedente de máquinas.
Portanto, esse algoritmo está preparado para responder à mudanças na carga ao
servidor, adquirindo e liberando máquinas de acordo com o resultado das medições
descritas acima. 

Entendido do que se trata Ranjan, partimos para a definição dos dados
necessários para obter o resultado pretendido, nesse caso, o número ‘ideal’ de
máquinas para satisfazer a necessidade de uma aplicação em dado momento. Tais
variáveis seguem descritas na tabela abaixo: \newline

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}b{11cm}|>{\small}c|}  
\hline
\centering{DESCRIÇÃO} & VARIÁVEL \\
\hline 
Número de requisições completas no intervalo de medição anterior & X \\
\hline 
Número de requisições que chegaram no intervalo de medição anterior & A\\
\hline 
Média de utilização das CPUs no intervalo de medição anterior & U\\
\hline 
Número atual de servidores & N\\
\hline
Utilização alvo (target utilization) & p\\
\hline  
\end{tabular}
\caption{\footnotesize Variáveis necessárias para a implementação do algoritmo
Ranjan.}
\end{center}
\end{table}

Utilizando-se das variáveis definidas na tabela 3, seguimos três passos
descritos no algoritmo para chegar-se ao valor de N’ (número requerido de
servidores para o próximo intervalo). A partir disso, podemos concluir que este
é um algoritmo relativamente simples e de fácil entendimento, dado que o
seguimento destes passos já resulta na variável que queremos encontrar, N'. A
tabela abaixo descreve cada um dos passos: \newline

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}m{11cm}|>{\small}c|}  
\hline
\centering{DESCRIÇÃO} & PASSO \\
\hline 
Computação de D considerando o valor da demanda média e o número de requisições
completas & 1. D = U/X \\
\hline 
Computa a utilização normalizada das máquinas, baseado no máximo entre as
requisições completas e as que chegaram, e o valor de D obtido acima  & 2. U’ = max(A,X).D\\
\hline 
Computa o número requerido de servidores, baseado em seu número atual, na
utilização normalizada das máquinas, e na utilização alvo (target)  & 3. N’ =
teto(N.U’/p)\\
\hline  
\end{tabular}
\caption{\footnotesize Passos a serem seguidos para a implementação do algoritmo
Ranjan.}
\end{center}
\end{table}

\hspace{0,43cm}\textbf{1.2 Implementação}\newline

O próximo passo da pesquisa envolveu verificar quais dos dados requeridos para a 
implementação de cada passo do algoritmo podem ser coletados pelo monitor de
aplicações da Amazon, o Amazon CloudWatch. Nesse caso, temos que, as métricas
são recebidas e agregadas pelo monitor em intervalos de no mínimo 1 minuto,
e a partir de sua documentação, observamos a disponibilidade de coleta, como
segue:    
\newpage

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}m{3cm}|>{\small}c|}  
\hline
\centering{POSSIBILIDADE DE COLETA} & VARIÁVEL \\
\hline 
\centering{check} & X \\
\hline 
\centering{check}  & A\\
\hline 
\centering{check}  & U\\
\hline  
\centering{check} & N \\
\hline
\centering{independe} & p \\
\hline
\end{tabular}
\caption{\footnotesize Possibilidade de coleta de cada dado pelo monitor de
aplicações CloudWatch.}
\end{center}
\end{table}

Analisando a tabela, vemos que os dados necessários para a implementação do
algoritmo são de possível coleta para o monitor, e podemos portanto,
partir para a implementação propriamente dita, a partir da caracterização de
Políticas a Alarmes.

A implementação foi realizada da seguinte forma. Temos um coletor de dados, que
está conectado ao monitor da aplicação, o Amazon CloudWatch. Ele será
responsável por obter os dados necessários para a implementação do algorítmo, e
fornecê-los à um outro objeto que calculará os passos descritos na tabela 4. A
partir desses cálculos, publicamos um alarme que verificará se o número de
máquinas em uso é igual ao número calculado pelo algoritmo. Caso seja diferente,
o alarme é acionado, e uma política relacionada à ele é ativada, realizando a
compra de máquinas, caso o valor ideal seja maior que o número atual de máquinas
em uso, ou a remoção do excedente, caso o valor ideal seja menor que o número
atual de máquinas em uso. 

Observamos então, que a implementação foi relativamente simples. Daí, podemos
citar dois fatores determinantes para essa facilidade. Primeiro, trata-se de
um algoritmo simples, com cálculos pequenos e poucas variáveis. Segundo, todas
estas variáveis são obtidas de maneira direta pelo monitor.\newline

\hspace{0,43cm}\textbf{1.3 Análise de Custo}\newline

Consideremos as 4 métricas necessárias para a implementação do algoritmo, número
de requisições completas no intervalo de medição anterior, número de requisições
que chegaram no intervalo de medição anterior, média de utilização das
CPUs, e número atual de servidores. Nesse caso, para o monitoramento detalhado
das instâncias, de um em um minuto, teremos:

\begin{center}
US\$ 0,50 por métrica X 4 métricas X 20 instâncias = US\$ 40,00/mês
\end{center}

Considerando os 2 alarmes definidos, o custo seria incrementado em

\begin{center}
US\$ 0,10 por alarme X 2 alarmes X 20 instâncias = US\$ 4,00/mês 
\end{center}

e portanto, um total de

\begin{center}
US\$ 40,00 + US\$ 4,00 = US\$ 44,00/mês
\end{center}

Num cenário para um ano, teríamos então,

\begin{center}
US\$ 44,00/mês X 12 meses = US\$ 528,00
\end{center}

Esse seria o custo para o monitoramento da aplicação, com o serviço de
escalonamento automático incluso, mas sem as taxas pela compra e utilização de
cada instância. \newline

\textbf{2.Algoritmo Urgaonkar}\newline

\hspace{0,43cm}\textbf{1.1 Funcionamento}\newline

Esse algoritmo propõe uma técnica de provisionamento dinâmico para aplicações
multi-camadas. Essa técnica funciona baseada em um modelo de filas para
determinar quantas máquinas escalonar para cada camada e uma combinação dos
métodos preditivo e reativo para determinar quando escalonar tais recursos (a
longo e curto prazo, respectivamente). De acordo com o journal de referência
estudado, experimentos foram realizados utilizando apenas o método preditivo,
depois apenas o reativo e outro combinando os dois, o qual obteve melhores
resultados.

Claramente podemos dividir esse algoritmo em duas partes: a que determina a
quantidade de recursos à serem escalonado para cada camada e a que determina
quando provisionar, a longo e curto prazo. Nesse caso, podemos separar esses
passos alocando-os sob responsabilidade de duas técnicas, a primeira parte
realizada por um modelo de filas (G/G/1) e a outra pelos métodos reativo e
preditivo combinados. Considerando isso, vamos primeiro conhecer como o
algoritmo funciona dentro dessas duas técnicas.\newline

\textbf{Modelo de filas para determinar quanto escalonar}\newline

O modelo de filas escolhido para esse cálculo, o G/G/1, consiste em uma fila de
requisições sendo atendidas por um único servidor, considerando uma distribuição
fixa de entrada e uma de saída. O cálculo da quantidade de máquinas necessárias
para satisfazer a demanda de uma dada aplicação é feito utilizando as variáveis
descritas na tabela abaixo:

\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}m{11cm}|>{\small}c|}  
\hline
\centering{DESCRIÇÃO} & VARIÁVEL \\
\hline 
Taxa de tempo de serviço para uma requisição na camada i & Si\\
\hline 
Média de tempo de resposta para a camada i  &  Di \\
\hline  
Variância do tempo de serviço & Sa \\
\hline
Variância do tempo entre as chegadas & Sb \\
\hline 
Taxa de chegada Y das requisições na camada i & Yi \\
\hline
Constante específica referente à camada i  & Bi\\
\hline 
Taxa de chegada de requisições numa seção (1/Z) i & Y\\
\hline 
Média de 'think-time' de uma sessão  &  Z\\
\hline  
Média de duração de uma sessão & T\\
\hline
Número n de servidores necessários para a camada i computar as requisições
segundo a taxa Yi (resultado procurado) & Ni\\ 
\hline
\end{tabular}
\caption{\footnotesize Variáveis necessárias para a determinação do número
ideal de máquinas.}
\end{center}
\end{table}

Essas variáveis são utilizadas na computação de duas fórmulas, uma responsável
por encontrar o valor de Yi, referente à taxa de chegada y na camada i (1) e
outra, que se utiliza desse valor para encontrar Ni, o número final de
servidores necessários (2). Descrevemos tais fórmulas nas equações abaixo:
\begin{equation}
Yi \geq \left [ Si + \frac{Sa + Sb}{2. (Di - Si)} \right ] ^ {-1}
\end{equation} e 
\begin{equation}
Ni = \left [ \frac{Bi.Y.T}{Yi.Z} \right ]
\end{equation} \newline

\textbf{Métodos preditivo e reativo para determinar quando escalonar}\newline

O método preditivo usa um workload preditor para determinar quando será o pico
de demanda nas próximas horas ou dias, e então, utiliza o modelo de
filas descrito anteriormente para determinação do número de servidores
necessários para processar esse pico de demanda. Essa predição é baseada em
uma verificação de demanda para cada hora do dia, considerando um histórico
dessa mesma hora analisada no decorrer dos dias anteriores. Podemos então
estimá-la como um 'high percentile' da distribuição de taxa de chegada de
requisições nessa mesma hora analisada à cada dia.
 
Já o método reativo é o responsável por verificações mais curtas, na ordem de
minutos, e procura por anomalias nas predições anteriores. Ou seja, casos em que
o algoritmo preditivo falhou, e a capacidade escalonada não é suficiente para
responder a um dado pico de demanda inesperado, por exemplo. Ele compara a taxa
de chegada da sessão atual nos últimos minutos com a taxa calculada pelo
algoritmo preditivo, chamado cálculo do erro de predição, e então, caso os
valores sejam diferentes e a taxa atual é maior que a esperada, uma medida
corretiva é tomada, para que o serviço seja capaz de atender a demanda no
momento. \newline

\hspace{0,43cm}\textbf{1.2 Implementação}\newline

Conhecendo o funcionamento do algoritmo e os dados necessários para sua
implementação, partimos para o próximo passo, a identificação das
variáveis relacionadas na tabela 6 que são de possível coleta pelo monitor
de aplicações, nesse caso, o Amazon CloudWatch. Verificamos, portanto, a
existência ou não da possibilidade de coleta, como segue na tabela abaixo:  
     
\begin{table}[h]
\begin{center}
\begin{tabular}{|>{\small}m{3cm}|>{\small}c|}  
\hline
\centering{POSSIBILIDADE DE COLETA} & VARIÁVEL \\
\hline 
\centering{uncheck} & Si \\
\hline 
\centering{check}  & Di\\
\hline 
\centering{uncheck}  & Sa\\
\hline  
\centering{uncheck} & Sb\\
\hline
\centering{uncheck} & Z\\
\hline
\centering{uncheck} & T\\
\hline
\end{tabular}
\caption{\footnotesize Possibilidade de coleta de cada dado pelo monitor de
aplicações CloudWatch.}
\end{center}
\end{table}

Note que, nem todas as variáveis relacionadas na tabela 6 foram incluídas nessa
verificação, pois, algumas são derivadas de cálculos que utilizam variáveis já
analisadas, como por exemplo Y que é obtida a partir de 1/Z.

De início, já após o estudo do funcionamento do algoritmo, percebemos que se
trata de um modelo mais complexo que o estudado anteriormente, Ranjan. Isso se
confirma a partir da análise da tabela acima, onde vemos que uma boa
parte das métricas necessárias para a computação das fórmulas incluídas no
algoritmo, não são de possível coleta pelo monitor, e nesse caso, não seria
possível sua implementação utilizando-se apenas das métricas pré-fornecidas pelo
CloudWatch.   

No entanto, para contornar essa dificuldade, existe uma abertura no serviço
oferecido pelo Amazon CloudWatch que permite a implementação de uma espécie de
monitor mais próximo da sua aplicação, que seja capaz de coletar as métricas
que não são cobertas por ele, e necessárias para a criação de políticas e
alarmes. Essas métricas seriam então publicadas no CloudWatch, e poderiam
ser utilizadas na implementação das regras do escalonador automático.      

Dessa forma, a implementação de Urgaonkar foi realizada tomando como base esse
conceito. Implementamos um monitor mais próximo à aplicação responsável por
coletar os dados previamente não oferecidos pelo CloudWatch, e um outro objeto
responsável por publicar essas novas métricas dentro do escalonador automático.

A partir disso, de maneira análoga ao esquema projetado para Ranjan, um objeto
responsável por calcular e computar as fórmulas descritas no algoritmo recebe
esses dados, e dos resultados de suas computações, um alarme é caracterizado
para verificar quando chegar a hora de escalonar, e uma política relacionada à
ele vai comprar mais máquinas ou remover o excedente destas, de acordo com a
predição do algoritmo. Um outro alarme será responsável por checar se houve erro
na predição, e caso ele seja acionado, uma outra política é definida para
comprar mais máquinas e atender à necessidade da aplicação de acordo com a correção
estimada na técnica reativa. \newline

\hspace{0,43cm}\textbf{1.3 Análise de Custo}\newline

Consideremos as 7 métricas necessárias para a implementação do algoritmo, taxa
de tempo de serviço para uma requisição em uma dada camada, média de tempo de
resposta para uma dada camada, variância do tempo de serviço, variância do tempo
entre as chegadas, taxa de chegada das requisições em uma dada camada, média de
'think-time' de uma sessão, e média de duração de uma sessão. Nesse caso,
para o monitoramento detalhado das instâncias, de um em um minuto, teremos:

\begin{center}
US\$ 0,50 por métrica X 7 métricas X 20 instâncias = US\$ 70,00/mês
\end{center}

Considerando os 2 alarmes definidos, o custo seria incrementado em

\begin{center}
US\$ 0,10 por alarme X 2 alarmes X 20 instâncias = US\$ 4,00/mês 
\end{center}

e portanto, um total de

\begin{center}
US\$ 70,00 + US\$ 4,00 = US\$ 74,00/mês
\end{center}

Num cenário para um ano, teríamos então,

\begin{center}
US\$ 74,00/mês X 12 meses = US\$ 888,00
\end{center}

Esse seria o custo para o monitoramento da aplicação, com o serviço de
escalonamento automático incluso, mas sem as taxas pela compra e utilização de
cada instância. É importante ressaltar que para esse algorítmo, a
maioria das métricas são customizadas, e nesse caso, sofreriam um
adicional por solicitações de API para uma quantidade de Get,
List, ou Put maior que 1 milhão ao mês, o que não se verifica para esse cenário
dada a relativamente pequena quantidade de máquinas. Caso considerássemos uma
aplicação real com uma demanda mais elaborada, teríamos mais servidores
em uso, e consequentemente, mais solicitações de API. Tais solicitações tem um
custo de \$0.01 por 1.000 solicitações de Get, List, ou Put, que seriam ainda
incrementadas nesse valor final.

Assim, concluímos que para este algorítmo, o custo de utilizá-lo dentro
desse serviço não é viável para o usuário, dado que o serviço ficaria
demasiado caro. \newline

\begin{center}
\textbf{CONCLUSÃO}
\end{center}

Ao término desta pesquisa, aumentamos a cobertura de testes do simulador
abordado, contribuindo de forma asignificativa para a confiabilidade dos
resultados obtidos através dos experimentos realizados, auxiliando em seu
processo de verificação e validação.

Entendemos também que o escalonamento automático de aplicações vem se
constituindo como um serviço em constante crescimento e que provê benefícios
claros quanto à disponibilidade de serviço e otimização de custos aos usuários
que o utilizam.

Diante disso, o estudo da implementação de algoritmos de provisionamento
dinâmico mostrou que, para algoritmos simples, como Ranjan, o serviço se comporta
de maneira satisfatória, tanto em relação à métricas técnicas, quanto à
métricas de negócio. Já a utilização de Urgaonkar, por se tratar de um algoritmo
mais complexo, implicaria em maiores custos para o usuário, que teria de pagar
taxas adicionais para o monitoramento de métricas que não são fornecidas
previamente pelo monitor de aplicações.

Dado que este é uma serviço em crescimento, e que vem obtendo cada vez mais
aceitação por parte das grandes empresas, vale a pena continuar a
estudar mais a fundo suas características, para então, conhecer até onde
é possível avançar tendo em vista o que já está sendo oferecido, além
de levar em consideração uma maior gama de algoritmos de
provisionamento dinâmico já estudados no meio da computação na nuvem.\newline

\begin{center}
\textbf{AGRADECIMENTOS}
\end{center}  

Ao CNPq pelo financiamento do projeto e pela concessão da bolsa PIBIC; 

Ao Laboratório de Sistemas Distribuídos (LSD), integrante do Centro
de Engenharia Elétrica e Informática, Departamento de Sistemas e Computação, onde
este projeto foi desenvolvido e realizado, pela oportunidade de realizar esta
pesquisa sob sua supervisão, e à todos os amigos de lá por todo o apoio e
contribuição;

À professora Raquel pela orientação, e todo conhecimento que passou
para mim, contribuindo para o andamento desta pesquisa e para a minha formação
de tantas maneiras.
\newpage

\begin{center}
\textbf{REFERÊNCIAS BIBLIOGRÁFICAS}
\end{center} 

MENASCÉ, D.; NGO, P. Understanding Cloud Computing: Experimentation and Capacity 
Planning. In: COMPUTER MEASUREMENT GROUP CONFERENCE, 2009, Dallas. \newline

RANJAN, S.; ROLIA, J.; FU, H.; KNIGHTLY, E. QoS-Driven 	Server
Migration. In: PROCEEDINGS OF IWQoS, 10., 2002, Miami Beach.\newline

URGAONKAR, B.; SHENOY, P.; CHANDRA, A.; GOYAL, P.; WOOD, T. Agile 
dynamic provisioning of multi-tier internet applications, ACM
Transactions on Autonomous and Adaptive Systems, New York, March 2008.
p.1-39.\newline

Amazon Auto Scaling. Disponível em <http://aws.amazon.com/pt/autoscaling/>
Acesso em 10 maio 2012.\newline

Amazon Auto Scaling Documentation. Disponível em
<http://aws.amazon.com/pt/documentation/autoscaling/> Acesso em 10 maio
2012.\newline

Amazon CloudWatch Documentation. Disponível em
<http://aws.amazon.com/pt/documentation/cloudwatch/>. Acesso em 19 maio
2012.\newline

Amazon CloudWatch. Disponível em <http://aws.amazon.com/pt/cloudwatch/>. Acesso
em 19 maio 2012. \newline

Netflix with Auto Scaling. Disponível em
<http://techblog.netflix.com/2012/01/auto-scaling-in-amazon-cloud.html> Acesso
em 28 maio 2012.\newline

Windows Azure. Disponível em <www.microsoft.com/azure/windowsazure.mspx>. Acesso
em 20 maio 2012.\newline

Windows Azure Monitoring. Disponível em <http://www.paraleap.com/>. Acesso em 21
maio 2012.\newline

\end{document}